| From: | Allan Odgaard |
| Date: | 08 Aug 99 at 23:30:18 |
| Subject: | Re: Drawing images on Intution |
From: Allan Odgaard <Duff@DIKU.DK>
On 08-Aug-99, Steffen wrote:
> [...] It should still be as gfx-board compatible as most aplications,
I used apostrophes around the word - FileX is an example of a non-"compatible"
program, it works fine, but it takes approximately 2 seconds for it to redraw
the contents of its window on a high or true colour screen :-(
> [...] Just because you have several aplications
> open leaving you too little gfx-mem to start a game,
If the window was resizeable, I could put it on a 1280x1024 screen, running 24
bit. There's enough memory for that, but if the program requires an extra
buffer in the same size then there's no room for that. No matter how few other
programs I have running. Which is why I called the solution "incompatible".
> Furthermore, i am not under the impression that my
> WB freezes because the blitter blits ? I thought that was one of the
> advantages of the custom chips on Amiga.
I said *if* the workbench had to make a copy of the entire screen, when moving
icons *then* it would freeze. Since icons are also created with the blitter
then an icon wouldn't be drawn until the blitter was done copying the screen.
> > [...]
> I can not see why you keep asuming the game will run 1024x768x16, wich seems
> to be the foundation of why my suggestion seems 'clumsy' to you.
I simply wants to ensure that the game isn't using solutions which are bad for
AGA, very bad for gfx cards, and which could easily have been done in a way
that wouldn't introduce such problems.
Quite a lot of Amiga owners has a graphics card, many of us can no longer use
AGA, because we have 31 KHz monitors, so it really sucks when downloading
something from AmiNet that insists on opening an AGA screen.
> I don't see
> either, why your method should be any faster or significantly mem-saving
> compared to just making a copy of the area destroyed by the card, and bliting
> it back when needed.
No, not compared to only making a copy of the card, but this wasn't what you
suggested - this was what the author was originally doing. I just had to point
out that in many cases, it's easier just to restore the background, and often
just as fast, plus saving memory.
> If deciding to use a pattern on the display, your method
> would be even slower.
Yes, if the pattern was copied in a naive way. But if you're re-using what's
already on the screen, you'll get an exponential increasing size of the source
bitmap, so an entire screen can be filled in no time.
> Having a dimension larger than the displayable is ONE of the features of
> superbitmap windows. Another is that the display can allways be recreated by
> the information of the superbitmap itself,
That'd require that the system would draw all visible things in two bitmaps,
which'd make it slower than smart or simpel refresh.
All visible data is in the screen bitmap and all that's not visible is in the
off screen bitmap. The system will exchange data when the contents of the
window is "scrolled" or when a window covers/uncovers your superbitmap window.
This is the so called feature of superbitmaps, but I've looked hard for a
program that actually use them, and no-one seems to do.
If anyone know of a program that does use superbitmap windows, please let me
know, as I need it for testing my betterlayers.library!
> You should check your information about superbitmap
> windows, and get back to me.
I find your arrogance a bit misplaced!
> When a window is backdrop, it does not overlap any other windows. Therefor,
> you don't have to take the backdrop window into account when calculating wich
> window is overlaping the other.
Calculation of clip rectangles happen when windows open, close, move or size.
Not for every draw operation.
Also, you can have many different backdrop windows, with different sizes, and
these will overlap each other, which is why layers.library handles backdropped
layers exactly as non-backdropped ones, because there is no difference.
Infact, a backdrop window would often be slower, because you're almost certain
it will be covered by another window, requiring that each draw operation gets
clipped, unlike a non-backdrop window, which can be put to front.
> Allso, it is not needed to render the screen,
> when you have a backdrop window on that screen, because the window overlaps
> the entire screen.
A full size window has the same effect - but it still has nothing to do with
the subject.
> Furthermore, the backdrop window actually uses the screens
> bitmap
All windows render directly to the screen bitmap. This is why you have to go
through your windows rastport, i.e. to get your renderings clipped correctly,
taking overlapping windows and boundaries into consideration.
> wich (via mcp) can be directed to be interleaved
This setting would also affect normal windows, as they use the same bitmap.
> I haven't checked this, but i bet you, if
How much are you prepared to risc? $50? :-)
> you check for it, you'll find backdrop windows are actually superbitmaps.
No they are not, I know that for a fact. I don't know from where you have your
info about layers, bitmaps & windows, but it seems that you've misunderstood
the basic concepts. So I see no point in continuing this discussion...
Regards Allan